-
Notifications
You must be signed in to change notification settings - Fork 64
Add fixes against race conditions #22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
ensuring that the monitor is declared a single time by becoming atomic. This approach protects also against race conditions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- in bloom filter, can we use RWMutex?
- can you add some bennchmarks?
) | ||
|
||
const defaultSize = 2 << 24 | ||
|
||
var seeds = []uint{7, 11, 13, 31, 37, 61} | ||
|
||
type BloomFilter struct { | ||
mu sync.Mutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can use RWMutex, then bf.Contains
can use bf.mu.RLock()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran some benchmarks, and these are the results:
- Current implementation (
sync.Mutex
):
goos: linux
goarch: amd64
pkg: github.com/penglongli/gin-metrics/ginmetrics
cpu: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
BenchmarkMiddlewareSamePort-4 10000 187130 ns/op
BenchmarkMiddlewareSamePort-4 10000 368713 ns/op
BenchmarkMiddlewareSamePort-4 10000 376937 ns/op
BenchmarkMiddlewareSamePort-4 10000 360904 ns/op
BenchmarkMiddlewareSamePort-4 10000 178943 ns/op
PASS
ok github.com/penglongli/gin-metrics/ginmetrics 19.239s
- Suggesteg implementation (
sync.RWMutex
, wherebf.Contains()
is protected bybf.mu.RLock()
):
goos: linux
goarch: amd64
pkg: github.com/penglongli/gin-metrics/ginmetrics
cpu: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
BenchmarkMiddlewareSamePort-4 10000 179478 ns/op
BenchmarkMiddlewareSamePort-4 10000 364757 ns/op
BenchmarkMiddlewareSamePort-4 10000 365689 ns/op
BenchmarkMiddlewareSamePort-4 10000 180693 ns/op
BenchmarkMiddlewareSamePort-4 9828 360628 ns/op
PASS
ok github.com/penglongli/gin-metrics/ginmetrics 18.937s
Benchtest comparison:
name old time/op new time/op delta
MiddlewareSamePort-4 295µs ±39% 290µs ±38% ~ (p=0.690 n=5+5)
As it can be seen the results are statistically indistinguishable. Increased the number of times benchmarks were run up to 25, and the result is still the same.
name old time/op new time/op delta
MiddlewareSamePort-4 278µs ±38% 264µs ±45% ~ (p=0.658 n=25+25)
I suggest to keep it the way it is.
@mjeshtri @hengfeiyang Sorry for the late reply, I'm working on this PR now |
Hi @mjeshtri
So I think it's actually a Thread-Safe Set. And i try to create a lot of goroutines concurrently to set the same value, it's okay. |
# Conflicts: # bloom/bloom.go
Hi @penglongli ,
This is interesting... If I remove the Lines 12 to 13 in 5dea4b6
Add() and Contains() method of BloomFilter (i.e. (*BitSet).Set() and (*BitSet).Test() ):
|
Hi @mjeshtri Because slice is not thread-safe, so the DataRace is detected. But I don't know if I can ignore that, so i create a post here: https://groups.google.com/g/golang-nuts/c/ai0eQtnas7A |
monitor
is declared a single time by becoming atomic. This approach protects also against race conditionsBloomFilter
thread-safemaster
branch or whenever commits are merged inmaster
.